familypediawikiaorg-20200214-history
Template talk:Showfacts children
01:54, September 20, 2009 (UTC) Say the children were stored in the mother article. Say the father article queries the mother article and caches the children-g1 properties locally. That way there is no need for complicated indirection schemes. Any queries for parents of children would always retrieve the parents. The downside is that they may not always be completely up to date. 06:50, September 30, 2009 (UTC) Possible typo in g9 and g10 They include "declare:children-list8=children-g9" and "declare:children-list8=children-g10". I can't see the "Edit facts" thing that should be where we still have a Special:EditData to fix. There was one near the bottom of "Showfacts person", now fixed. — Robin Patterson (Talk) 11:34, April 19, 2010 (UTC) Fixed the numbering typos. Thurstan (talk) 05:27, February 4, 2013 (UTC) 2010 new look See Forum:Children box. — Robin Patterson (Talk) 23:59, October 25, 2010 (UTC) Adding spouses Can one of our experts please consider incorporating another column for "|?Joined_with"? -- Robin Patterson (Talk) 05:17, February 4, 2013 (UTC) :Done. Thurstan (talk) 05:41, February 4, 2013 (UTC) ::Thank you. -- Robin Patterson (Talk) 06:32, February 6, 2013 (UTC) Column widths The "Name" column extends nearly halfway across the page. Names very rarely reach that limit. I presume they will settle themselves with line breaks if they do reach whatever limit we set. That leaves the other columns rather cramped, which often leads to unbalanced table taking up more lines than it should because one or two of the other columns usually contain much more text. I've reduced the "35%" to "20%". But no way can I get it to show. I've republished the group page, the main template, an article, the article's sensor page, and the article again, in that order. Help! -- Robin Patterson (Talk) 06:32, February 6, 2013 (UTC) :Fixed. The syntax wasn't working (it didn't appear in the source HTML), don't ask me why. When I fixed that, it was still being over-ridden by , which was setting the width of the first column to 50% (I have removed that). You may want to tweak some more. Thurstan (talk) 06:57, February 6, 2013 (UTC) Failure to show heading using spouse data Thurstan has recently explained why a page had no "Children" heading despite displaying a woman's children (via her husband's page): "That is a long-standing bug: because they are her husband's second family, the heading is not displayed." I presume that that is (logically?) because the spouse's second child table does not display a new heading (except the tabular heading with partners' names inside it). Seems to me that the coding needs to display a heading (even if there's no data - as we do for - so that contributors can add text if they like). Then it should display any tables it can find. Maybe I'll look into it if my internet doesn't misbehave too much. -- Robin Patterson (Talk) 01:23, December 29, 2015 (UTC) I think I see a glimmer of hope. First few lines go like this (if we add a few line breaks for easy reading): | } } } } } } } } } }| Children That suggests to me (a person with admittedly very little coding ability) that the heading is printed only if the person has his or her own children. If we moved it to the top it would show every time. I suspect that further down in the coding, in the areas where (as determined above) there is no child coding for the individual and therefore the spouse coding is searched, is an instruction to copy a particular item of spouse code with a "Children" heading if it has one. So we would need to cut out that heading instruction. -- Robin Patterson (Talk) 01:39, December 29, 2015 (UTC) :I vote that we don't show the heading if there are no children, which is the way it is now. Thurstan (talk) 02:58, December 29, 2015 (UTC) ::We should certainly show it if there are children, which is not the way it is now. It is quite absurd to see a table of children under an unrelated and possibly confusing heading such as "Siblings". If you don't feel like fixing that bug, how about accepting that there's no real harm in having a Children heading with no table under it but providing a good space for contributors to add children in any way they like without having to use the form (which often doesn't work!)? -- Robin Patterson (Talk) 04:35, December 31, 2015 (UTC) :::Well, how about the opposite compromise: until I fix it, switch off the display from the spouses' page. Thurstan (talk) 04:49, December 31, 2015 (UTC) :::As you consider the existing behaviour unacceptable, and there are several other errors in the "copy from spouse" logic, I have remove that code altogether, pending repair. Thurstan (talk) 05:59, December 31, 2015 (UTC) ::::Children displayed with occasionally no proper heading is much better than no children displayed. One of the advantages of SMW (matching most commercial genealogy programs) is that people don't have to enter children on each parent's page. Turning off the whole "copy from spouse" logic seems like overkill and makes Familypedia distinctly poorer. The only error in its logic that I know about is the one this section is about. Please describe the "several other errors" you know about, so that we can plan a comprehensive solution. -- Robin Patterson (Talk) 00:25, January 1, 2016 (UTC) :::::The logic for counting the families is wrong: if someone is the 2nd wife of their first husband, then the children are counted as their second family rather than their first. The wrong property is populated, and the heading is not displayed. Also if someone's husband has children with no partner specified, then these children are added to their named spouse. I am happy to leave the logic as it was, pending a fix. You seemed to be saying that you would rather have it broken pending a fix. This would make FP much poorer to display a "Children" heading on the pages for people who died as infants. Thurstan (talk) 01:47, January 1, 2016 (UTC) :::::The headings are incorrectly formatted too, because the template doesn't know the spouses have been swapped. Thurstan (talk) 03:01, January 1, 2016 (UTC) ::::::Thank you for the details. I have long wondered whether a woman's group1 would have any problem listing her husband's group2; that does need fixing in the medium term, as does the "no partner" one. And I accept that some readers would not want to see a children heading on a page of someone who died too young (though that would soon be very rare if we persuaded all contributors to delete the children template in such cases and ran a bot to delete it from most existing qualifying pages). So I repeat that "Children displayed with occasionally no proper heading is much better than no children displayed" - with the whole spouse thing disabled, thousands of FP women have "lost" children and descendants; please "leave the logic as it was, pending a fix" and revert to the only occasionally annoying setup we had before. -- Robin Patterson (Talk) 10:53, January 1, 2016 (UTC) Fixing the aforementioned bugs I have reverted that change. Now we must design a fix. The present "direct" case works, so if we can change the "spouse" case to share that code, it would also work. So one overall design is to visit all the spouses, and rather than display the children on-the-fly, accumulate all the parameters to pass to a single template call at the end (the most reliable way to know to print the heading is to know that there are some children to be displayed). I can see two different ways that might achieve this: the first more conservative than the second. However I think that some Lua coding is required in each version: #we can recode the existing logic to generate a parameter string, rather than displaying a table. However the SMW arraymaptemplate function doesn't tell you what the item number is for the item that you are processing, and computing that number potentially uses redundant SMW queries. This is where the major error in the present coding occurs. If we code an Lua function to replace arraymaptemplate which passes the item number to the template, then the correct number will be available to the lower-level template. However, I do not know if this approach of having one template generate the parameter list for another actually works! #we can recode all the existing logic in a Lua program, which has the advantage that any SMW query is only issued once. However, I am not sure how to communicate all the results of an SMW query to the Lua code. The quickest way forward is probably a step-wise process: creating the arraymaptemplate replacement function in the existing logic, which will fix the properties, and produce the heading for the case when the first family contains children. Then we can look at refining it along the "shared code" lines to cover the other cases too. Thurstan (talk) 21:21, January 1, 2016 (UTC) :You sound much more positive than you did on my talk page. I've invited rtol to have a look at this page because he had a bit to do with editing the template. An idea that came to me in bed was to have "Family:(name)+(name)" pages (not necessarily in a separate namespace); they could have the same childbox format as we have now, with known and unknown parents, not needing group numbers, and could be transcluded (after a programmed search) into either party's page where required; they might simplify sibling searches too. Lua might solve everything itself, though! -- Robin Patterson (Talk) 06:01, January 2, 2016 (UTC) "Edit child facts" is not working "Edit child facts" is not working for me. Can we please disable its display until we can get it working again? -- Robin Patterson (Talk) 12:32, May 15, 2016 (UTC) Our expert did that. Now it seems, miraculously, to be working again, and the "Edit children facts" link is still usable at the top of the "Edit with form" page. -- Robin Patterson (Talk) 05:35, May 4, 2018 (UTC) Brigham Young et al User:MainTour has now given us the 50-plus wives of Mormon pioneer Brigham Young. More than ten of them had children. So we should add several dozen child groups. Before tackling that messy task, I want to be sure that the coding we have in that section is OK. Does our talk of Lua potentially affect it? -- Robin Patterson (Talk) 04:01, October 26, 2017 (UTC) Links near top of form? In August 2009, the architect of our SMW wrote a blog post about unbunching templates. Part of what he envisaged was: "What we will do is place buttons for editing children, residences and other events in tables across the top of the main edit form and all the subforms". Several such buttons - or links - are at the top of the main form but the children form has none; is the addition of that sort of navigation panel an improvement we could instigate? -- Robin Patterson (Talk) 05:35, May 4, 2018 (UTC) :??? I can see them. Thurstan (talk) 06:10, May 4, 2018 (UTC) ::OK - yes, sorry, I see them on the editing page for the subform just above the editing box; I was taking Phlox's "across the top of the main edit form and all the subforms" wording too literally. He meant "all the subforms' edit pages". So - is the coding to achieve a similar menu on any future subforms easy to find and incorporate? -- Robin Patterson (Talk) 11:41, May 4, 2018 (UTC) :::Yes: template shows the links. Thurstan (talk) 11:44, May 4, 2018 (UTC) Possible variation in heading level For an individual with many partners, it would be good to have an option to reduce the level of the heading so as to produce a table of contents something like this: :Siblings :Early life :Marriages and children ::1st wife: Mary ::Children ::2nd wife: Jean ::Children :Academic career :Residences At present if we make the wife headings lower than the "Marriages and children" heading we get this: :Siblings :Early life :Marriages and children ::1st wife: Mary :Children ::2nd wife: Jean :Children :Academic career :Residences - where "2nd wife" appears to be a subheading under a "Children" heading. --- Robin Patterson (Talk) 23:36, February 6, 2019 (UTC)